[BUG] Preserve input dtype in shift_scale_invariant zero-padding - #3773
[BUG] Preserve input dtype in shift_scale_invariant zero-padding#3773Jorge-Polanco-Roque wants to merge 2 commits into
Conversation
The zero-padding in the shift branches of the shift-scale-invariant distance used an untyped np.zeros (float64), so shifted_y could not unify with float32 input inside the numba-compiled function, raising a TypingError. Pass dtype=y.dtype in both branches. Fixes aeon-toolkit#3722
Thank you for contributing to
|
|
The |
Reference Issues/PRs
Fixes #3722.
What does this implement/fix? Explain your changes.
shift_scale_invariant_distance(andKSpectralCentroid, which uses it) raised a numbaTypingErroronfloat32input: the zero-padding in the shift branches of_univariate_shift_scale_invariant_distancewas built with an untypednp.zeros, which defaults tofloat64, soshifted_ycould not unify across the branches (float32fromy,float64from the padded ones). Passingdtype=y.dtypeto both zero-padding branches keeps everything at the input dtype.Does your contribution introduce a new dependency? If yes, which one?
No.
Any other comments?
Verified
shift_scale_invariant_distanceandKSpectralCentroidnow fit/run onfloat32, matching thefloat64result.PR checklist
For all contributions
test_shift_scale_invariant_distance_float32); verified it fails without the fix.ruffis green.